1. Field of the Invention
This invention relates to the field of hardware and software performance analysis and workload characterization, and more particularly to workload characterization in application server environments.
2. Description of Related Art
The field of application servers is a fast-growing and important field in the computing industry. As web applications and other distributed applications have evolved into large-scale applications that demand more sophisticated computing services, specialized application servers have been developed to provide a platform supporting these large-scale applications. Applications that run on application servers are generally constructed according to an N-tier architecture, in which, for example, presentation, business logic, and data access layers are kept separate. The application server space is sometimes referred to as “middleware”, since application servers are often responsible for deploying and running the business logic layer and for integrating, and interacting with, various enterprise-wide resources, such as web servers, databases, and backend or legacy systems.
Application servers typically provide application services for tasks that web applications and other networked applications commonly need. Application servers often incorporate these services and components into an integrated platform specialized for creating web applications. The platform may leverage various standard software component models, such as the Common Object Request Broker Architecture (CORBA), the (Distributed) Component Object Model (COM/DCOM), Enterprise JavaBeans™ (EJB), etc., or the platform may provide its own software component model or may extend standard component models.
An application server may implement application component containers. An application component container, or simply “container”, generally refers to a software framework that manages and supports the execution of application components. For example, a Java™ based application component container may include a container that functions according to the Java™ 2 Platform Enterprise Edition Specification, v1.3 (J2EE™). In many instances, J2EE™ services in a J2EE™ application server tier, such as web services, enterprise beans, message beans, etc., may be implemented using a container environment. This container environment may provide services (e.g. security, transaction, life-cycle management) that are used by server applications written in Java™ for the J2EE™ platform. In a J2EE™ environment, a web component may be assembled into a J2EE™ web module and deployed within a web container, and an enterprise bean may be assembled into a J2EE™ EJB module and deployed within an EJB container. One example of such an environment is the JES Application Server (frequently referred to as AppServer) from Sun Microsystems, Inc. With AppServer, application developers may create their applications that are accessed through Web services (HTTP, XML/SOAP, JMS, etc.) or rich-client paths such as RMI/IIOP. An example of a J2EE™ application is an online retail E-commerce web site that serves as a product catalog, has a shopping cart, and a checkout module.
A growing number of Java 2 Enterprise Edition (J2EE™) applications are middleware applications that use a variety of technologies (web, xml, relational and object databases, portal, messaging, transaction, legacy, etc.) and support various lines of business. Many modern on-line services are frequently implemented using a multi-tiered approach, placing different services on different tiers of the total system. A typical system configuration may be made up of three tiers, for example, a web server tier, a application server tier, and a database tier.
The first, or client tier may include a number of different clients communicating with application components (e.g., servlets, server pages, beans) in the middle tier or application server. The clients may communicate with the application server via a network, an example of which may be the Internet. A backend tier may include various system resources, such as databases or other information systems.
Application components within a tier typically communicate with remote application components in an adjacent tier. For example, multiple users with access to an application component configured to operate in a client tier (e.g., an application client accessible via a web browser) may initiate requests to remote application components configured to operate in a middle tier, such as an application server. Each application component in the middle tier may, in turn, initiate requests to the backend tier, such as to system resources, on behalf of the application component in the client tier. For example, an application component in the middle tier may receive a remote request from a web browser operating in the client tier and in response invoke another application component to access a database object in the backend tier, for example. The application component accessing the backend tier may then provide a response to the application in the middle tier, which may complete the remote request, in this example.
A user of a multi-tier computer system may connect to the Internet and access the system using a web browser. The browser may send a request for service to a node in the web server tier. In some cases, the requested information may be in the form of a static page stored on the web server nodes; in these cases, the page may be returned immediately to the requesting browser. In other cases, the requested information may be developed dynamically for the specific request. These requests may be forwarded to a node in the application server tier. A forwarded request may invoke a particular application component or program that determines or generates the content for the request and may deliver this back to the web server, which in turn may deliver this back to the requesting browser.
Furthermore, the performance of the system may be a major factor in a user's perception of the service delivered by the system, namely response time. Systems maintaining service-level agreements (e.g., 90-th percentile response time <1.2 sec) may attract and retain customers for the site, while systems exhibiting sub-standard levels of performance may discourage customers from visiting the site. From the website administrator and deployer's perspective, throughput may be an important metric, as well as response time. Throughput measurements may provide the ability to gauge the system's ability to handle multiple user requests concurrently.
Applications running in an application server are frequently difficult to understand from a performance perspective (given their distributed nature and complexity) and they have traditionally not been characterized in any automated fashion. Application server vendors may provide performance tools and utilities. However, most performance tools focus on optimizations at development time, providing very limited capabilities to use them for any other task. Several Java™ performance tools provide the ability to identify “hot” methods or lines of code. When compared to other methods, the “hot” methods may be using more resources such as processor (CPU), memory (heap), lock (latency), disk and network 10, etc., affecting the response time of a service. Many Java™ performance tools use the Java™ virtual machine profiler interface [JVMPI] and also the Java™ virtual machine tool interface [JVMTI]; JVMTI, included in the Java Development Kit v1.5 [JDK], provides the ability to instrument Java™ classes statically, at load-time or dynamically. Several profilers, such as JFluid [JFLUID], provide developers an intuitive graphical user interface to display “hot” methods. However, workload characterization of standard benchmarks traditionally takes significant time and resources. It is generally non-trivial to characterize a customer/user application in sufficient detail due to time and resource constraints or due to an application's limited lifetime.
Studies of system performance generally require accurate descriptions of the system workload. Typically, the goal of a performance study is to gain an understanding of how the system is behaving currently and to make recommendations about corrective steps that may result in improved performance in the future. Each of these tasks may depend on having several key ingredients. One is an accurate description of the system components and how they interoperate. Another is an accurate description of the demands being made by the elements of the workload for use of these components. It may be important to understand the behavior of both the hardware and software environments and methods in order to get a comprehensive view of resource usage and performance. Traditional methods of workload characterization have been focused on either a high-level, software-centric analysis or a low-level, processor-centric analysis and have not tied hardware and software analysis together. Often, characterization is focused on a single application or a limited set of benchmarks. However, workload characterization determined by running benchmarks is often an inaccurate estimate of workload performance for any particular application since real applications do not utilize system resources exactly the same as benchmarks.